========================================================================= INFO-ATARI16 Digest Thu, 25 Jan 90 Volume 90 : Issue 98 Today's Topics: AES function appl_tplay() and appl_trecord() Elite! - Avoiding police GEM, BIOS, XBIOS, GEMDOS bindings for Sozobon MWC (was Re: dissassembly) Networking Subscription Where is AES entry point?!? (Please Help Me. :-) ---------------------------------------------------------------------- Date: Thu, 25 Jan 90 19:53:19 GMT From: Michael Mueller Subject: AES function appl_tplay() and appl_trecord() I'd like to use the functions appl_tplay()| & appl_trecord(). Unfortunately, I still have old ROMs of 1985 (don't ask me the TOS version). As far as I could u nderstand, these functions only work with newer TOS versions. Does anybody know what is the bug in the old ROMs ? Is it reasonably possible t o implement these functions by soft ? Where could I get the listings (in C, ev. in ASM) ? N.B.: These functions allow to record every event. You can store these events, and play them back when you want. I think there was a question about it recentl y... Michael Mueller, Brain Research Institute, Zuerich, Switzerland ------------------------------ Date: Thu,25 Jan 90 11:02:56 GMT From: R.D.Chafer%sysc.salford.ac.uk@NSFnet-Relay.AC.UK Subject: Elite! - Avoiding police Message-ID: <25 Jan 90 11:02:56 A10326@UK.AC.SALF.C> Even with the docking computer on SLOW, the police will not shoot while the docking computer is on (my version anyway). Robert ------------------------------ Date: 25 Jan 90 18:20:37 GMT From: dartvax!eleazar.dartmouth.edu@CS.BU.EDU (Clark L. Breyman) Subject: GEM, BIOS, XBIOS, GEMDOS bindings for Sozobon Message-ID: <18829@dartvax.Dartmouth.EDU> What are the preferred binadings to GEM (AES/VDI), GEMDOS, BIOS and XBIOS for Sozobon? Or is the best way to teach oneself GEM... by writing bindings? Much app, Clark ------------------------------ Date: 25 Jan 90 18:32:50 GMT From: sjsca4!greg@uunet.uu.net (Greg Wageman) Subject: MWC (was Re: dissassembly) Message-ID: <1990Jan25.183250.20884@sj.ate.slb.com> Opinions expressed are the responsibility of the author. In article <893@per2.UUCP> dag@per2.UUCP (Daniel A. Glasser) writes: >> >If you're writing code that you eventually hope for >> >other people to use, don't hard-code magic numbers like 32K into your >> >screen manipulation routines. [In fact, don't even use 32K. You only >> >need, at most, 32256, to get 32000 bytes on a 256 byte boundary, eh?] > >Well -- I had to use some value when I wrote the example. I could have >used a #define, but at the time it seemed like this would remain unchanged >for the immediate future, and we didn't want to go through all the extra >trouble (in the example) to calculate the memory needs of the new display. >(It was not a GEM example, and S.A.L.A.D. was not yet written, and even when >these two conditions are met, it is still more than a few lines of code >to figure this out in the general case for all possible future display >modes, if its possible at all. I don't know what happens when you use >a Moniterm.) These examples were supposed to be short and illustrate >proper use of the documented routine/function/feature, without adding >lots of extra stuff that might confuse or intimidate the novice ST programmer. Since TOS fails to provide a system call to return you a correctly-aligned, properly-sized chunk of memory useable as display memory, it is *impossible* not to hard-code certain assumptions into the code to do this. MWC needs no defending on this point. >In my honest opinion, biased as it may be, the MWC manual is the single >best volume for programming the ST published to date. It needs revision, >bugfixing, and maybe some other tweeking (new GEM examples, etc.) and >the compiler should be updated, but it is still a very good package at a >good price. There are some occasions where it leads to more frustration than useful results, but care in marking corrections discovered through trial-and-error will eventually produce a very comprehensive manual. I consult my MWC manual first (since it's only one volume and fits comfortably in my hand), and only when something doesn't work as advertised do I break out the backup, the dreaded Developer's Docs. Since the MWC manual seems to have been written from experience rather than specs, it tends, when there is a disagreement, to be the more-frequently-correct one. In many cases the MWC examples demonstrate important points that aren't mentioned elsewhere. On the other hand, at least one of the examples doesn't work at all (I think it was the one that demonstrated the use of fsel_input()). A new versions was published in the errata with version 3.0.6 of the compiler, but *it* didn't quite work, either. These are the sorts of problems that extend the development time of what should otherwise be a quick and easy program. However, since the wise programmer writes routines that are as general as possible, and reuses them as frequently as possible in new code, (or at least reuses code fragments) one should find the learning curve getting steeper with each project, as one discovers how to use more and more pieces of TOS properly. This has certainly been my experience. Copyright 1990 Greg Wageman DOMAIN: greg@sj.ate.slb.com Schlumberger Technologies UUCP: ?uunet,decwrl,amdahl?!sjsca4!greg San Jose, CA 95110-1397 BIX: gwage CIS: 74016,352 GEnie: G.WAGEMAN Permission is granted for reproduction provided this notice is maintained. ------------------------------ Date: 25 Jan 90 15:06:14 GMT From: cs.umn.edu!thelake!steve@ub.d.umn.edu (Steve Yelvington) Subject: Networking Message-ID: <0025900906143026@thelake.mn.org> [In article <9001250807.AA00801@ucbvax.Berkeley.EDU>, K331672@AEARN.BITNET (Gerfried Klein) writes ... ] > > Hi all | > > Please could somebody tell me how to reach the CI$ network from BITNET ? > Or is there a better way to contact ANTIC via e mail ? > > Hey folks, it would be a wonderfull thing if someone could sommon the > networking information (which networks are reachable, archive-hosts, ..) > so that beginners in networking could fetch this info. > But maybe there is one out there, would be fine | > Convert the CIS user ID from the form 7xxxx,yyy to 7xxxx.yyy (replace the comma with a dot). Then mail to the following address: 7xxxx.yyy%compuserve.com@saqqara.cis.ohio-state.edu The appropriate newsgroup for questions of this sort is comp.mail.misc. John Chew posts a (mostly monthly) guide to internetwork mailing; I received the most recent copy about three days ago, so it should be available on your system. -- Steve Yelvington at the (thin ice today*) lake in Minnesota UUCP path: ... umn-cs.cs.umn.edu!thelake!steve *16 cars through the ice so far this year! Yes, you, too, can have that sinking feeling.... ------------------------------ Date: 25 Jan 90 18:58:51 GMT From: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!mrsvr.UUCP!jupiter.uucp!krieg@ucsd.ed u (Andrew Krieg) Subject: Subscription Message-ID: <1953@mrsvr.UUCP> SUBSCRIBE INFO-A16 -- ========================================================================= = Andrew Krieg The Marvel Historian = = G.E. Medical Systems - CT - New Berlin, WI = = USENET: krieg@jupiter.med.ge.com = ========================================================================= = "Holy one track Batcomputer mind!" - Robin = ========================================================================= ------------------------------ Date: 25 Jan 90 15:23:12 GMT From: cs.umn.edu!thelake!steve@ub.d.umn.edu (Steve Yelvington) Subject: Where is AES entry point?!? (Please Help Me. :-) Message-ID: <0025900923123027@thelake.mn.org> [In article <10489@saturn.ucsc.edu>, rome@ucscb.UCSC.EDU writes ... ] > I was up all last night trying to call a file selector using > assmebler code mixed with a C source file. > > I am trying to send the extended information to the AES file > selector function that is picked up and utilized by LGF's File Selector. > > In the documentation for the LGF FS, there is in-line assembler > code provided to type into a C program to get it to call the file selector. > > One of the instructions is "bsr AES" ... Well, Laser C does > not seem to have any constant "AES" defined. > > Does anyone know the absolute memory entry point for the AES? > Can anyone help? We'll see. > It doesn't work that way. AES is entered through a 68000 trap, not through an address. I think Charles Johnson has made some unwarranted assumptions about what can be found in the C bindings for the AES. The label "aes" may or may not be defined. I don't know how Laser does it. The following information may help you determine what he is looking for. The AES is invoked by: * copying the arguments to the function (file selector call, for example) into "mailboxes." There are arrays of mailboxes, typically labeled control[], global[], int_in[], int_out[], addr_in[], and addr_out[]. I don't recall their sizes. The args are copied from left to right in a C binding. Integers go into int_in[]; addresses (such as pointers to strings) go into addr_in[], etc. * the control[] mailbox array is stuffed with an AES opcode number (control[0]). Three magic numbers are stuffed into control[1] through [3]. These numbers tell the AES how many integers and addresses to expect. The numbers are contained in the dlibs crystal.s module, if you're interested. * an array of 6 addresses is loaded with the addresses of each of the mailbox arrays (control, global, etc., as above). This array typically is called the AES parameter block. * The address of the AES parameter block is loaded into d1. * The magic number 200 is loaded into d0. * trap #2 kicks AES into action. I think I've got all this right, but no promises. :-) I wrote some AES bindings in C for Sozobon before GEMFAST came out, and this is the strategy that I figured out from various published (non-Atari) documents and code snippets. -- Steve Yelvington at the (thin ice today*) lake in Minnesota UUCP path: ... umn-cs.cs.umn.edu!thelake!steve *16 cars through the ice so far this year! Yes, you, too, can have that sinking feeling.... ------------------------------ Date: Thu, 25 Jan 90 09:12:00 -0900 From: UNSUBSCRIBE Chris Hamman ------------------------------ End of INFO-ATARI16 Digest V90 Issue #98 ****************************************